Introduction to Helm
Learn about package managers and how Helm came into action.
We'll cover the following
Background#
Every operating system has at least one packaging mechanism. Some Linux distributions use RPM or APT. Windows uses Chocolatey, and macOS uses Brew. Those are all package mechanisms for operating systems. But why does that matter in the context of Kubernetes?
We might say that Kubernetes is a scheduler, while Windows, Linux, and macOS are operating systems. This is correct, but it’s only partly true. We can think of Kubernetes as an operating system for clusters, while Linux, Windows, and macOS are operating systems of individual machines. The scheduler is only one of the many features of Kubernetes, and saying that it’s an operating system for a cluster is a more precise way to define it. It serves a similar purpose as, say, Linux, except that it operates over a group of servers. As such, it needs a packaging mechanism designed to leverage its modus operandi.
While there are quite a few tools we can use to package, install, and manage applications in Kubernetes, none is as widely used as Helm. It’s the de facto standard in the Kubernetes ecosystem.
Helm as a package manager#
Helm uses “charts” to help us define, install, upgrade, and manage apps and all the surrounding resources. It simplifies versioning, publishing, and sharing applications. Helm was donated to the Cloud Native Computing Foundation, thus landing in the same place as most other projects that matter in the Kubernetes ecosystem.
Helm is mighty yet simple to use. If we need to explain Helm in a single sentence, we could say that it’s a templating and packaging mechanism for Kubernetes resources. But it’s much more than that, even though those are the primary objectives of the project.
It organizes packages into charts. We can create them from scratch with the Helm create command or convert existing Kubernetes definitions into Helm templates.
Helm uses a naming convention, which, as long as we spend a few minutes learning it, simplifies the creation and maintenance of packages and navigation through those created by others.
How Helm works
In its simplest form, the bulk of the work in Helm is about defining variables in values.yaml and injecting them into Kubernetes YAML definitions by using entries like {{ .Values.ingress.host }} instead of hard-coded values. But Helm is not only about templating Kubernetes definitions but also about adding dependencies as additional charts. Those can be charts we’ve developed and packaged, or charts maintained by others, usually for third-party software. The latter case is compelling since it allows us to leverage the collective effort and knowledge of a much wider community.
Advantages of Helm#
One of the main advantages of Helm is that it empowers us to have variations of our applications without needing to change their definitions. It accomplishes that by allowing us to define different properties of our application when it’s running in different environments. Helm does that through the ability to overwrite default values, which, in turn, modify the definitions propagated to Kubernetes. It greatly simplifies the process of deploying variations of our applications to different environments, which can be separate namespaces or even other clusters.
Once a chart is packaged, it can be stored in a registry and easily retrieved and used by people and teams with sufficient permissions to access it.
In addition to those main features, it offers many other goodies, like, for example, the mechanism to roll back releases. There are many others and it can take some time to learn them all. Fortunately, it takes almost no effort to get up to speed with those that are most commonly used. It’s a helpful and easy-to-learn tool that solves quite a few problems that were not meant to be solved with Kubernetes alone.
Now, let’s define a few requirements and see whether we can fulfill them with Helm.
Summary: Packaging, Deploying, and Managing Applications
Defining a Scenario